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Defense  Transportation  EDI 
Interface  Integrity 


Background 

In  February  1995,  the  Defense  Finance  and  Accounting  Service  -  Indianapo¬ 
lis  Center  (DFAS-IN)  began  paying  freight  transportation  electronic  invoices 
using  a  new  automated  system,  Defense  Transportation  Payment  System 
(DTRS).  The  operating  concept  for  DTRS  calls  for  Department  of  Defense  (DoD) 
shipping  activities  to  pre-position  shipment  information  on  the  Military  Traffic 
Management  Command's  (MTMC's)  CONUS  Freight  Management  (CFM)  sys¬ 
tem  for  subsequent  transmission  to  DTRS.  All  transactions  are  to  occur  using 
electronic  data  interchange  (EDI)  techniques. 

After  extensive  development  and  testing,  these  transactions  are  occurring  on 
a  regular  basis.  However,  DTRS  rejects  approximately  7  percent  of  the  carriers' 
EDI  invoices  —  about  1,200  per  month  —  because  of  the  unavailability  of  match¬ 
ing  electronic  government  bill  of  lading  (GBL)  shipment  information. 

While  1,200  invoice  rejections  out  of  approximately  17,000  monthly  EDI 
invoices  are  currently  manageable,  the  number  of  rejections  will  increase  dra¬ 
matically  when  tire  Defense  transportation's  payment  program  is  fully  imple¬ 
mented.  Nonetheless,  these  missing  GBLs  cause  a  significant  disruption  of 
normal  payment  processing  at  DFAS-IN,  MTMC,  and  the  shippers,  requiring 
labor-intensive  manual  research  to  locate  electronic  GBLs. 

The  Defense  transportation  community's  inability  to  correct  its  processing 
problems  imposes  several  other  penalties  on  the  payment  program,  including 
the  following: 

♦  The  government  may  pay  interest  to  carriers  due  to  the  violation  of  the 
mandatory  prompt  payment  requirement. 

♦  Late  bill  payment  places  an  adverse  financial  burden  on  some  carriers. 

♦  Some  valid  bills  from  carriers  are  rejected  and  must  be  resubmitted  on 
paper. 

♦  Missing  shipment  information  raises  distrust  among  Defense  transportation 
trading  partners  and  erodes  carrier  industry  confidence  in  DoD's  EDI  pay¬ 
ment  procedures. 

Dr.  John  Hamre,  Under  Secretary  of  Defense  (Comptroller),  and  Dr.  Paul 
Kaminski,  Under  Secretary  of  Defense  (Acquisition  and  Technology),  in  a  24  July 
1995  memorandum  called  for  accelerated  use  of  EDI  techniques  in  paying 
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transportation  invoices.  These  data  problems,  however,  are  delaying  the  trans¬ 
portation  community's  ability  to  satisfy  their  requirement. 


Overview  of  EDI  Operating  Concept 

Figure  1  provides  an  overview  of  DoD's  operating  concept  for  using  EDI 
techniques  to  pay  transportation  invoices.  It  is  initiated  when  a  carrier  picks  up 
a  shipment  at  a  DoD  shipper  activity.  The  activity  uses  the  services  of  a  central 
translation  activity  to  formulate  and  transmit  the  GBL,  Accredited  Standards 
Committee  (ASC)  X12  Transaction  Set  858,  Shipment  Information,  to  MTMC. 
This  process  employs  electronic,  but  not  EDI,  interfaces  in  the  information 
exchange. 


ASC  XI 2  Transaction  Set  214 


Note:  The  dotted  lines  represent  processes  that  were  planned  in  the  original  operating  concept  but  have  not  yet  been  imple¬ 
mented.  Although  not  shown  in  the  figure,  all  EDI  transactions  require  ASC  XI 2  Transaction  Sets  997,  Functional  Acknowledg¬ 
ment,  from  receiving  activities.  DLA  =  Defense  Logistics  Agency;  TDCC  =  Transportation  Data  Coordinating  Committee. 


Figure  1 . 

Defense  Transportation  Traffic  Flow  Supporting  the  EDI  Operating  Concept 


The  CFM  system  acknowledges  receipt  of  the  electronic  GBL  with  two  trans¬ 
actions.  An  ASC  X12  Transaction  Set  997,  Functional  Acknowledgment,  indi¬ 
cates  receipt  of  the  transaction;  it  may  also  reject  the  transaction  because  of  a 
syntactical  error.  A  TDCC  Transaction  Set  994  acknowledges  receipt  of  a  trans¬ 
action  by  the  application  program  after  its  translation  from  EDI;  it  may  also 
request  a  correction  to  particular  data  fields  or  reject  the  transaction  on  the  basis 
that  critical  information  is  either  missing,  incorrect,  or  the  transaction  references 
a  duplicate  GBL  number. 

After  receiving  an  electronic  invoice  from  a  carrier,  DTRS  requests  an  elec¬ 
tronic  GBL  from  the  CFM  system  using  Transaction  Set  213,  Motor  Carrier  Ship¬ 
ment  Status  Inquiry.  If  the  CFM  system  cannot  locate  a  pre-positioned  GBL,  it 
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returns  a  Transaction  Set  214,  Transportation  Carrier  Shipment  Status  Message, 
to  DTRS  to  indicate  that  no  record  is  on  file. 

The  intended  purpose  of  Transaction  Set  214  is  to  alert  DFAS-IN  when  a  car¬ 
rier  has  submitted  an  invoice  for  which  there  is  no  shipment  information  on 
record.  However,  GBL  information  may  also  be  missing  because  of  system  or 
software  failures  or  data  quality  problems.  The  only  means  for  distinguishing 
between  a  legitimate  Transaction  Set  214  and  a  variety  of  performance  anomalies 
is  through  manual  research. 


Improving  Interface  Integrity 

The  absence  of  GBLs  that  correspond  to  carrier  invoices  adversely  impacts 
DoD's  payment  process  in  two  ways:  invoices  are  returned  for  carriers  to  resub¬ 
mit  on  paper  and  the  manual  effort  expended  to  locate  missing  GBLs  is  time- 
consuming  and  expensive.  The  reasons  why  GBLs  may  not  be  available  arise 
because  of  the  following: 

♦  Interface  control.  Records  are  lost  between  the  shipper  and  central  transla¬ 
tion  facilities.  While  built-in  acknowledgment  processes  provide  adequate 
protection  for  the  exchange  of  EDI  transactions,  the  integrity  of  those  inter¬ 
faces  is  undermined  by  inadequate  reconciliation  and  monitoring  proce¬ 
dures  for  the  non-EDI  exchanges. 

♦  Software  failures.  Software  problems  in  the  CFM  system  interfere  with  GBL 
retrieval  and  processing.1 

♦  Data  quality.  Poor  data  quality  affects  GBL  availability  in  two  ways: 

►  A  transaction  is  available,  but  inaccessible.  This  situation  occurs  when 
the  GBL  number  and  government  bill  of  lading  office  location  code 
(GBLOC)  do  not  match. 

►  A  transaction  is  unavailable  due  to  prior  rejection.  Transactions  may 
not  be  available  to  the  CFM  system  because  they  have  been  rejected  due 
to  critical  data  errors. 

Lack  of  adequate  interface  controls  and  software  problems  each  accounted 
for  about  40  percent  of  the  missing  GBLs  over  the  period  of  this  study,  while 
poor  data  accounted  for  the  remaining  20  percent.  Sometimes,  however,  as  in 
the  case  of  fraudulent  invoices,  GBLs  are  supposed  to  be  missing.  Our  research 
shows  that  the  transportation  payment  process  has  no  efficient  way  of  tracking 
missing  electronic  GBLs  back  to  the  shipper  to  determine  their  validity.  As  a 


1  Recently,  the  CFM  system  has  experienced  two  separate  software  problems  that 
result  in  missing  GBL  information.  One  interrupts  the  search  process  before  it  is  success¬ 
fully  completed;  the  other  prohibits  generation  of  a  Transaction  Set  214.  MTMC  is  in  the 
process  of  correcting  these  problems. 
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result,  it  also  lacks  the  means  to  distinguish  between  legitimately  and  errone¬ 
ously  missing  GBLs. 


Interface  Control 

The  loss  of  EDI  transactions  has  been  suspected  to  be  occurring  between 
either  shipper  systems  and  the  CFM  system  or  DTRS  and  the  CFM  system. 
Upon  investigation,  we  discovered  that,  while  EDI  exchanges  occasionally  fail, 
they  are  not  major.  Errors  in  EDI  transmissions  and  EDI  processing  failures  are 
easily  detected.  EDI  interfaces  owe  their  integrity  to  the  automatic,  translator¬ 
generated  Functional  Acknowledgments  that  identify  missing  transactions  and 
report  the  syntactical  correctness  of  each  transaction. 

The  majority  of  data  losses  arise  because  the  CFM  system  never  received 
shipment  information  from  a  shipper  activity.  In  other  words,  the  missing  trans¬ 
actions  are  not  lost  by  the  EDI  network  but  are  lost  between  the  shipper  activity 
and  its  central  translation  facility  —  before  they  are  translated  to  an  EDI  format. 

Shipment  information  originating  at  a  shipper  activity  is  sent  in  a  flat-file 
format  to  a  central  translation  facility.  This  interface  does  not  protect  the  move¬ 
ment  of  shipment  information  by  automated  acknowledgments  like  EDI  inter¬ 
faces.  Moreover,  the  shipper  loses  control  over  the  data  after  they  are  entered 
into  the  shipper's  system.  At  the  Defense  Depot  -  Richmond,  for  example,  the 
shipper's  computer  display  indicates  that  data  are  transmitted  to  the  central 
translation  facility  upon  completion  of  GBL  entry.  In  fact,  no  transmission  will 
yet  have  taken  place.  Rather,  the  newly  entered  shipment  data  are  passed  to  a 
communications  center,  bundled  with  other  flat  files,  and  transmitted  to  the  cen¬ 
tral  translation  facility  at  a  later  time.  The  shipper,  isolated  from  these  subse¬ 
quent  stages,  is  unable  to  detect  any  breakdown  in  the  flow  of  flat-file  shipment 
information. 


Cause  of  the  Problem 

All  DoD  transportation  systems  use  file  transfer  protocol  (FTP)  to  exchange 
both  EDI  and  non-EDI  shipment  information  with  trading  partner  systems.  FTP 
is  a  reliable  protocol  —  protected  by  usual  communications  protocol  error 
checks —  but  it  fails  to  provide  adequate  end-to-end  transmission  assurance. 
While  failures  in  FTP  flat-file  transmission  are  infrequent,  they  do  occur  because 
of  human  error  or  temporary  technical  difficulties.  FTP  provides  inadequate 
reporting  for  such  failures  to  protect  unattended  operation. 

EDI  exchanges  between  Defense  transportation  systems  are  accompanied  by 
Functional  Acknowledgment  transactions,  which  overcome  the  weakness  of  FTP 
reporting.  Such  end-to-end  EDI  acknowledgments  provide  adequate  internal 
data  controls  and  permit  a  timely  awareness  whenever  incomplete  exchanges 
occur.  However,  Functional  Acknowledgments  alone  —  without  proper 
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resources  and  management  procedures  to  monitor  and  reconcile  problems  — 
allow  transmission  problems  to  go  unnoticed. 

Non-EDI  interfaces  (unlike  EDI  interfaces)  are  vulnerable  to  the  vagaries  of 
transmission  errors.  They  are  not  protected  by  overarching  end-to-end 
acknowledgments;  they  also  lack  the  reconciliation  processes  for  transferred  data 
acknowledgments.  As  a  result,  data  losses  occur  in  non-EDI  exchanges,  usually 
without  awareness. 


Recommended  Solution 

Defense  transportation  system  managers  need  to  develop  formal  audit  pro¬ 
cedures  when  exchanging  EDI  data.  At  a  minimum,  those  procedures  should 
direct  resources  to  review  Functional  Acknowledgment  reports,  reconcile  excep¬ 
tions,  and  communicate  problems  to  trading  partners. 

Shippers  and  central  translation  sites  need  to  establish  flat-file  acknowledg¬ 
ments  similar  to  the  Functional  Acknowledgments  employed  in  EDI  exchanges. 
A  flat-file  acknowledgment  can  be  a  simple  message  returned  to  a  shipper  loca¬ 
tion  that  cites  GBL  numbers  and  a  count  of  GBLs  received  in  each  flat-file 
transmission. 

As  with  EDI  exchanges,  a  non-EDI  acknowledgment  process  will  be  useful 
only  if  accompanied  by  reconciliation  procedures.  Shipper  systems  can  be 
enhanced  to  produce  logs  as  an  automatic  byproduct  of  generating  shipment 
information,  and  those  logs  should  be  reconciled  against  the  transmission 
acknowledgments.  Such  reconciliation  would  enable  a  trading  partner's  timely 
recognition  of  discrepancies  between  GBLs  sent  and  those  received;  it  would 
also  permit  early  correction  or  retransmission  at  the  shipper  sites.  Figure  2  pre¬ 
sents  proposed  concept  of  operations  supporting  such  features. 

In  response  to  Dr.  Hamre's  and  Dr.  Kaminski's  initiative  for  accelerated  use 
of  EDI  techniques  in  paying  transportation  invoices,  LMI  developed,  and  the 
U.S.  Transportation  Command  (USTRANSCOM)  distributed,  a  concept  of  opera¬ 
tions  incorporating  these  features.  As  a  result,  the  Military  Services  and  DLA  are 
now  implementing  improvements  to  their  interface  controls. 


Software  Failures 

Modifying  or  upgrading  software  carries  a  high  risk  for  introducing  errors. 
While  conducting  research  for  this  task,  two  such  errors  resulted  from  a  change 
in  the  hardware  platform  of  the  CFM  system.  Both  resulted  in  a  breakdown  in 
the  CFM  system's  ability  to  deliver  GBLs  to  DTRS.  The  first  error  caused  an 
occasional  cessation  of  processing  during  the  CFM  system's  searches  for  GBLs  to 
match  invoices  that  DTRS  received.  The  other  error  resulted  in  the  system  refus¬ 
ing  to  generate  Transaction  Set  214  notifications  for  some  GBLs  not  on  file  in  the 
CFM  system.  We  cite  these  particular  problems  because  they  typify  the  kinds  of 
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software  failures  the  Defense  transportation  EDI  program  will  continue  to  expe¬ 
rience  as  it  expands  and  matures.  The  significance  of  these  problems  is  that  they 
are  indistinguishable  from  the  other  causes  of  missing  GBLs. 

ASC  XI 2  Transaction 

GBL  transmittal  log  Set  858  transmittal  log 


GBL  acknowledgment  log  ASC  XI 2  Transaction  Set  997 

acknowledgment  log 

Note:  The  dotted  lines  represent  processes  that  should  be  added  to  the  current  operating  concept  to  support  adequate  internal 
controls. 


Figure  2. 

Interface  Controls  Operating  Concept 


Cause  of  the  Problem 

Many  of  these  types  of  software  problems  occur  because  of  inadequate  test¬ 
ing  of  all  aspects  of  the  software  performance  in  a  new  platform  environment. 
Clearly,  operations  were  transferred  to  the  new  platform  prematurely.  Although 
these  particular  software  problems  were  not  perceived  immediately,  MTMC 
eventually  identified  their  causes.  However,  when  it  determined  the  affected 
GBLs,  MTMC  failed  to  identify  those  GBL  numbers  for  DFAS-IN,  which 
adversely  compounded  the  effects  of  the  problem. 


Recommended  Solution 

A  sound  approach  to  handling  software  problems  is  to  take  all  necessary 
measures  to  minimize  their  effects  on  operations.  We  believe  it  is  imperative  for 
the  program  managers  of  all  Defense  transportation  systems  to  assign  separate 
(i.e.,  off-line)  hardware  facilities  for  parallel  system  testing  when  developing, 
modifying,  or  upgrading  software.  New  software  or  hardware  should  be 
employed  in  operations  only  after  all  perceivable  aspects  are  identical  between 
operational  and  test  software.  MTMC  has  recognized  this  need  and  has  taken 
steps  that  should  avoid  the  recurrence  of  similar  problems  in  the  future. 

Additionally,  whenever  a  software  problem  occurs  —  even  after  thorough 
testing  —  all  trading  partners  who  may  be  affected  need  to  be  informed  of  the 
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nature,  potential  implications,  and  actions  being  taken  toward  correction  of  the 
problem. 


Data  Quality 


Poor  data  quality  contributes  to  transaction  problems  in  two  ways:  GBLs 
are  available,  but  they  are  inaccessible  because  of  a  mismatch  of  search  keys;  and 
GBLs  are  not  available  because  they  were  rejected  for  critical  data  problems. 


Transaction  Available,  but  Inaccessible 

The  CFM  system  retrieves  electronic  GBLs  using  two  search  keys:  GBL 
number  and  GBLOC,  which  together  uniquely  identify  a  shipment  and  its  ship¬ 
per.  Shippers  provide  the  GBL  number  and  GBLOC  to  carriers  and  the  CFM 
system  —  by  paper  for  the  carrier  and  electronically  to  the  CFM  system.  Carrier 
invoices  transmitted  to  DTRS  also  contain  them  and  a  corresponding  pair  are 
transferred  in  each  request  for  shipment  information  (Transaction  Set  213)  sent 
to  the  CFM  system.  When  the  search  values  in  Transaction  Set  213  match  those 
in  a  corresponding  electronic  GBL,  the  CFM  system  retrieves  the  required 
information. 

Occasionally,  either  the  GBL  number  or  GBLOC  on  a  carrier's  invoice  does 
not  match  the  search  key  in  the  CFM  system's  data  base;  when  this  situation 
occurs,  the  retrieval  of  data  fails.  Even  though  the  desired  GBL  may  be  present 
in  the  data  base,  the  system  is  unable  to  provide  DTRS  with  the  GBL  needed  to 
support  carrier  payment. 


Cause  of  the  Problem 

A  mismatch  of  GBL  number  or  GBLOC  may  occur  because  a  carrier  trans¬ 
fers  the  information  incorrectly  from  a  paper  GBL  to  the  electronic  invoice.  The 
paper  GBL  may  be  soiled  and  difficult  to  read,  letters  or  numbers  may  be  trans¬ 
posed  during  data  entry,  or  the  carrier  may  use  an  incorrect  GBLOC. 
(Co-located  shipper  activities  are  identified  by  separate  GBLOCs,  which  confuse 
some  carriers.)  Carrier-related  problems  account  for  only  7  to  10  percent  of  the 
missing  GBLs. 

Another  reason  the  search  keys  may  fail  to  match  is  that  shippers  occasion¬ 
ally  issue  an  erroneous  GBLOC,  and  a  carrier,  recognizing  the  problem,  corrects 
the  information  on  its  invoice.  In  those  cases,  the  GBL  number  and  GBLOC  may 
be  accurate,  but  they  will  not  match  values  found  in  the  CFM  system's  data  base. 
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Recommended  Solution 


Shippers  need  to  provide  electronic  GBLs  to  carriers,  as  initially  planned  for 
the  Defense  transportation  system.  However,  carriers  have  indicated  an  unwill¬ 
ingness  to  invest  in  integrating  electronic  shipment  information  with  their 
invoice  application  without  some  additional  incentives.  Those  incentives 
include  electronic  GBLs  citing  the  carriers'  "pro-number"  (i.e.,  the  waybill  or 
freight  bill  number)  or  offering  carriers  financial  considerations  (such  as  shorten¬ 
ing  the  payment  cycle  for  EDI  bills).  Although  not  as  important  as  implement¬ 
ing  interface  controls,  encouraging  more  carriers  to  become  EDI-capable  will 
improve  the  data  quality  of  invoices  and  the  likelihood  of  locating  available 
GBLs. 

Co-located  shipping  activities  should  also  use  consolidated  GBLOCs,  which 
would  be  less  confusing  to  carriers  and  assist  in  eliminating  incorrect  GBLOCs 
on  carrier  invoices.  In  addition,  carrier  instructions  should  direct  carriers  that 
recognize  an  incorrect  GBLOC  to  notify  the  shippers  for  release  of  a  GBL  correc¬ 
tion  notice. 


Transaction  Unavailable  Due  to  Prior  Rejection 

The  CFM  system  rejects  GBL  transactions  because  of  poor  data  quality  or 
missing  data  in  shipper-supplied  electronic  GBLs.  When  the  problems  are  iden¬ 
tified,  the  CFM  system  returns  a  Transaction  Set  994  to  the  shipper  indicating 
that  the  GBL  has  been  rejected  and  identifying  required  corrections.  Shippers 
are  responsible  for  correcting  and  returning  rejected  shipment  information. 


Cause  of  the  Problem 

Some  data  errors  occur  because  shipper  systems  do  not  perform  compre¬ 
hensive  source  data  editing.  Presently,  the  first  time  critical  data  elements  are 
scrutinized  for  correct  content  is  when  electronic  GBLs  arrive  at  the  CFM  system. 
GBLs  are  frequently  rejected  because  they  have  not  been  subjected  to  the  same 
edits  before  leaving  the  shipper  sites.  Furthermore,  no  centrally  maintained 
standard  reference  files  exist  to  assist  shippers  with  the  critical  source  data 
editing. 

Responding  to  a  Transaction  Set  994  invokes  a  manual  process  at  shipper 
sites  or  the  central  translation  facility.  Because  of  inadequate  procedures  and 
controls  governing  the  correction  process,  shipper  response  is  slow  and  unreli¬ 
able.  Similarly,  sending  correction  notices  to  carriers  is  a  manual,  labor-intensive 
process  that  lengthens  the  time  for  returning  corrected  shipment  information  to 
the  CFM  system. 
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Recommended  Solution 


To  eliminate  these  data  quality  problems,  which  account  for  as  much  as 
10  percent  of  the  missing  electronic  GBLs,  shippers  need  to  develop  source  data 
edits  that  are  identical  to  those  in  the  CFM  system.  The  use  of  standard  source 
data  edits  will  significantly  reduce  the  number  of  GBL  transactions  that  the  CFM 
system  rejects  and,  thereby,  minimize  the  error-correction  workload. 

For  errors  not  caught  by  shipper  source  edits,  shippers  (including  the  central 
translation  facility)  need  to  establish  automated  error-correction  procedures.  In 
addition,  MTMC  needs  to  establish  procedures  for  monitoring  outstanding  GBL 
corrections.  Those  procedures  should  include  the  creation  of  computer  logs 
identifying  GBLs  returned  to  shippers  for  correction  and  corrected  GBLs 
returned  to  MTMC.  These  types  of  logs  would  assist  in  maintaining  agreed- 
upon  turnaround  times  for  error  correction.  The  memorandum  of  understand¬ 
ing  between  MTMC  and  DFAS-IN  on  addressing  the  operating  procedures  for 
paying  DoD's  transportation  bills  electronically  specifies  that  the  CFM  system 
must  use  a  Transaction  Set  214  to  respond  to  an  unprocessable  Transaction 
Set  213  from  DTRS  when  the  CFM  system  has  previously  rejected  the  requested 
Transaction  Set  858.  A  Transaction  Set  214  with  a  "UP"  code  (in  lieu  of  a  Trans¬ 
action  Set  858)  verifies  the  existence  of  a  valid  shipment  and  notifies  DTRS  that 
the  shipper  is  processing  the  information. 

Figure  3  proposes  an  operating  concept  for  an  automated  error-correction 
capability  involving  remote  shipper  sites,  central  translation  facility,  CFM  sys¬ 
tem,  and  DTRS.  USTRANSCOM  proposed  this  concept  to  the  Military  Services, 
MTMC,  DLA,  and  DFAS-IN  in  response  to  Dr.  Hamre's  and  Dr.  Kaminski's  ini¬ 
tiative  to  accelerate  the  use  of  EDI  for  payment  of  transportation  invoices.  These 
automated  error-correction  processes  are  now  being  implemented. 


TDCC  Transaction  Set  994  TDCC  Transaction  Set  994 

transmittal  log  transmittal  log 


i  • 

t  TDCC  Transaction  1 


Corrected  ASC  X12  Transaction  Corrected  ASC  XI 2  Transaction 

Set  858  receipt  log  Set  858  receipt  log 


Note:  The  dotted  lines  represent  processes  that  should  be  added  to  the  current  operating  concept  to  support  automated  error 
correction.  Although  not  shown  in  the  figure,  all  transactions  (EDI  and  non-EDI)  require  Functional  Acknowledgments  by  receiving 
activities. 


Figure  3. 

Proposed  Automated  Error-Correction  Operating  Concept 
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We  also  found  that  the  CFM  system  uses  Transaction  Set  994  to  reject  Ship¬ 
ment  Information  transactions  for  legitimate  shipments  that  have  been  errone¬ 
ously  given  a  previously  assigned  GBL  number.  Such  transactions  are 
mistakenly  diagnosed  as  duplicates  because  the  CFM  system  recognizes  and 
rejects  any  transactions  bearing  a  previously  received  GBL  number  and  GBLOC. 
The  advent  of  automated  GBL  generation  has  complicated  the  regulation  of  GBL 
control  numbers.  Shippers  often  lack  effective  procedures  to  identify  and  pre¬ 
vent  occasional  duplicate  assignments,  particularly  those  supporting  multiple 
sites. 

The  lack  of  control  in  GBL  number  generation  is  more  serious  than  the  Ship¬ 
ment  Information  transactions  that  are  incorrectly  rejected.  The  General  Services 
Administration's  (GSA's)  assignment  of  GBL  numbers  is  a  controlled  process 
that  is  intended  to  create  a  unique,  traceable  identification  for  every  shipment. 
GSA  and  DoD  should  convene  a  task  group  for  establishing  controls  and  proce¬ 
dures  that  disallow  assignment  of  duplicate  GBL  numbers.  When  those  controls 
and  procedures  are  in  place,  the  need  for  shipper  corrections  of  misassigned  GBL 
numbers  should  be  eliminated. 


GBL  Tracking 


In  DoD's  transportation  payment  operating  concept,  the  primary  purpose  of 
an  Transaction  Set  214,  Transportation  Carrier  Shipment  Status  Message,  is  to 
alert  DFAS-IN  when  a  shipment  has  not  occurred  and  a  carrier  has  submitted  a 
fraudulent  or  erroneous  invoice.  The  concept  calls  for  shipper  systems  to  receive 
a  Transaction  Set  213  from  the  CFM  system  when  a  shipment  record  cannot  be 
located.  Shippers  respond  either  with  the  appropriate  electronic  GBL  or  a  status 
message  indicating  that  DTRS  should  reject  the  invoice. 

Presently,  when  the  CFM  system  does  not  have  a  requested  GBL  on  file,  it 
faxes  a  manually  prepared  list  to  the  shipper  in  lieu  of  Transaction  Set  213.  The 
CFM  system  also  returns  a  Transaction  Set  214  to  DTRS  indicating  that  no  record 
is  on  file.  The  problem  occurs  because  DTRS  cannot  differentiate  between  a 
Transaction  Set  214  indicating  the  existence  of  an  invalid  invoice  and  one  that 
reports  the  temporary  unavailability  of  a  GBL.  This  situation  results  in  all  GBLs 
not  found  in  the  CFM  system's  data  base  requiring  manual  resolution. 


Cause  of  the  Problem 

Shipper  systems  lack  the  capability  to  receive  Transaction  Sets  213  and 
respond  with  either  the  missing  GBL  or  a  Transaction  Set  214.  Shippers  also  lack 
the  capability  to  automatically  locate  missing  shipment  information.  Resolving 
these  problems  is  a  tedious,  labor-intensive,  manual  process  that  often  results  in 
the  unavailability  of  GBL  shipment  information  when  it  is  required. 
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Recommended  Solution 


Central  translation  facilities  need  to  develop  the  capability  to  receive  Trans¬ 
action  Sets  213  from  the  CFM  system  and  respond  either  with  the  appropriate 
electronic  GBL  or  a  Transaction  Set  214  indicating  the  shipment  did  not  occur 
and  that  DTRS  should  reject  the  invoice.  They  also  need  to  convert  the  Transac¬ 
tion  Set  213  into  an  appropriate  shipment  inquiry  message  and  deliver  it  to  the 
non-EDI  shipper  site.  Also,  the  central  translation  facility  needs  to  replace  "none 
found"  shipment  status  messages  from  its  shipper  sites  with  Transaction  Sets  214 
forwarded  to  the  CFM  system. 

Figure  4  presents  an  operating  concept  for  controlling  and  reconciling  miss¬ 
ing  shipment  information  among  satellite  shipper  sites,  central  translation  facili¬ 
ties,  CFM  system,  DTRS,  and  carriers. 


ASC  XI 2  Transaction  ASC  XI 2  Transaction 


i  found"  message 

i 

Transaction  «  Transaction  Set  858  i 

Set  858  or  1  or  Transaction  Set  21 4  1 

1 

Transaction  Set  21 4  y 

y 

Acknowledgment  log 

ASC  XI 2  Transaction 

ASC  XI 2  Transaction 

Sets  858/214 

Sets  858/214 

receipt  log 

receipt  log 

Note:  The  dotted  lines  represent  processes  that  should  be  added  to  the  current  operating  concept  to  support  electronic  GBL 
tracking.  Although  not  shown  in  the  figure,  all  transactions  (EDI  and  non-EDI)  require  Functional  Acknowledgments  by  receiving 
activities. 


Figure  4. 

Electronic  GBL  Tracking  Operating  Concept 


Summary 


The  problem  of  missing  GBLs  in  the  Defense  transportation  payment  proc¬ 
ess  can  be  minimized  by  implementing  the  original  concept  of  operations  and 
adopting  a  few  system  enhancements.  The  outstanding  implementation  activi¬ 
ties  include  the  capability  for  tracking  GBLs  and  transmitting  electronic  GBLs  to 
carriers.  The  enhancements  include  providing  acknowledgments  for  all  inter¬ 
face  transmissions  and  procedures  for  monitoring  the  acknowledgments.  These 
actions  are  necessary  if  Defense  transportation's  EDI  program  is  to  succeed. 


11 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OPM  No.0704-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources 
gathering,  and  maintaining  the  data  needed,  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of 
information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway, 
Suite  1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Information  and  Regulatory  Affairs,  Office  of  Management  and  Budget,  Washington,  DC  20503. 


1 .  AGENCY  USE  ONLY  (Leave  Blank) 


2.  REPORT  DATE 


3.  REPORT  TYPE  AND  DATES  COVERED 


4.  TITLE  AND  SUBTITLE 


5.  FUNDING  NUMBERS 


Defense  Transportation  EDI  Interface  Integrity 


6.  AUTHOR(S) 

William  T.  James  III 


C  DASWO 1-95-C-001 9 


PE  09021 98D 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Logistics  Management  Institute 
2000  Corporate  Ridge 
McLean,  VA  22102-7805 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


LMI-  DF501MR1 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Deputy  Director  for  Finance  Operations 

Defense  Finance  and  Accounting  Service  —  Indianapolis  Center 
8899  E.  56th  Street 
Indianapolis,  IN  46249-0501 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 


11.  SUPPLEMENTARY  NOTES 


12a.  DISTRIBUTION/AVAILABILITY  STATEMENT 

A:  Approved  for  public  release;  distribution  unlimited 


12b.  DISTRIBUTION  CODE 


13.  ABSTRACT  (Maximum  200  words) 

The  problem  of  missing  government  bills  of  lading  (GBLs)  in  the  Defense  transportation  payment  process,  while  produced  by  a  variety  of  causes,  can  be 
minimized  through  completion  of  the  original  concept  of  operations  and  by  implementing  a  few  system  enhancements  to  accommodate  some  lessons  learned. 
Program  completion  involves  measures  to  improve  GBL  tracking  and  transmission  of  electronic  GBLs  to  the  carriers.  Enhancements  include  providing 
acknowledgments  for  all  interface  transmissions  and  adequate  resources  and  procedures  for  monitoring  those  acknowledgments.  Failure  to  improve  the  integrity  of 
data  exchange  across  all  interfaces  will  seriously  jeopardize  the  future  of  Defense  transportation’s  electronic  data  interchange  program.  Implementing  the 
recommendations  in  this  report  will  move  the  program  toward  the  full  achievement  of  its  intended  expectations. 


14.  SUBJECT  TERMS 

EDI,  Interface,  Integrity,  Government  Bill  of  Lading,  GBL(s),  Electronic  GBL(s),  Defense  Transportation  Payment, 
Internal  Control(s),  GBL  Tracking. 


15.  NUMBER  OF  PAGES 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

Unclassified 


NSN  7540-01-280-5500 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

Unclassified 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 


Unclassified 


20.  LIMITATION  OF  ABSTRACT 


Standard  Form  298,  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  239-18 
299-01 


